There are well-known mechanisms for detecting an error and various mechanisms for automatically correcting the detected error and recovering from the error when a data error occurs owing to an occurrence of a fault in a register file etc. in a common information processing apparatus. In a checking process in making a prototype of an information processing apparatus and in manufacturing a practical information processing apparatus, it is necessary to confirm that a mechanism for detecting the error using parity, a mechanism for detecting and correcting the error using an error-correcting code (ECC), a mechanism for automatically rerunning an instruction by hardware in response to the detection of the error, a mechanism for rerunning a program by a software interrupt in response to the detection of the error, etc. correctly function individually. That is, it is necessary to debug these mechanisms. In the descriptions below, these mechanisms to be debugged are generally called “mechanisms to be debugged”. To debug the mechanisms to be debugged, it is necessary to embed a circuit for generating a pseudo fault (that is called a “simulated fault” below) to simulate an occurrence of a fault in a central processing unit (CPU) in an information processing apparatus in advance.
FIG. 1 is a functional block diagram illustrating the configuration of a conventional central processing unit in which a circuit for generating a simulated fault is embedded. FIG. 1 is a view obtained by extracting a portion relating to an occurrence of a simulated fault from among components configuring a CPU 100.
In a normal operation, an operation unit 102 performs an operation using data read from a register file 101, and writes back an operation result to the register file 101. A control unit 103 controls the entire execution of the operation, and the control includes, for example, an instruction to write data to the register file 101.
In addition, the CPU 100 includes a mechanism to be debugged (not illustrated in the attached drawings) realized by hardware, firmware, and/or software, and a simulated fault data generation circuit 104. The control unit 103 also controls switching between a normal mode in which the normal operation is performed as described above and a debug mode for debugging the mechanism to be debugged.
The simulated fault data generation circuit 104 is provided in the path from the operation unit 102 to the register file 101. In the normal mode, the operation result output from the operation unit 102 is input to the simulated fault data generation circuit 104, and the simulated fault data generation circuit 104 outputs the input as is to the register file 101.
On the other hand, in the debug mode, the control unit 103 instructs the simulated fault data generation circuit 104 to generate a simulated fault. Then, according to the simulated fault generation instruction, the simulated fault data generation circuit 104 generates simulated fault data from the operation result input from the operation unit 102 and outputs it to the register file 101. Typical simulated fault data is data obtained by inverting the bit value(s) of one or more bits in the input operation result.
In the above-mentioned operation, since the operation result is converted into simulated fault data and then written to the register file 101, an occurrence of a fault is simulated. The thus simulated fault, that is, a pseudo fault is used in debugging a mechanism to be debugged.
The well-known documents about the generation of a simulated fault include, for example, patent documents 1 through 4.
The device according to the patent document 1 includes a syndrome bit setting unit capable of setting an arbitrary syndrome bit, and a selector for selecting one of the output from a normally used syndrome bit producing circuit and the output from the syndrome bit setting unit. The output of the selector is decoded by a syndrome bit decoding circuit, and a data correcting circuit obtains the exclusive disjunction (XOR) of a decoding result and the data stored in a register. Therefore, data in which an error has been produced in an arbitrary bit is output from the data correcting circuit by the selector selecting the syndrome bit setting unit.
The circuit according to the patent document 2 includes a control circuit as a combination of a counter and a decoder so that all patterns of errors correctable by the error correction circuit are settable. The control circuit outputs error generation control bits corresponding to respective bits of data and ECC. A simulated fault generating circuit computes the XOR between each of the error generation control bits and a corresponding bit in the data or a corresponding bit in the ECC. Therefore, it becomes possible to generate simulated faults of all patterns of errors correctable by the error correction circuit.
According to a circuit of the patent document 3, in a central processing unit in a microprogram control system, a fault generation flip-flop is set for only one clock and a fault is notified if a fault instruction flip-flop is set and at least one of a mode flip-flop indicating that fault generation is limited to only once and a history flip-flop indicating that a fault has already been generated is not set when a time signal indicating the timing of generating a simulated fault indicates the logic level of “1”.
The circuit according to the patent document 4 is capable of setting whether or not to generate a simulated fault for a register in which a fault is to be detected, correspondingly to each of a plurality of parity check circuits for performing a parity check on a value of a corresponding register. If a setting is made to generate a simulated fault, an XOR circuit inverts a parity bit of a target register in which a fault is to be detected.
As described above, there are various known techniques of generating a simulated fault. On the other hand, a CPU provided with a plurality of register files to read data in a high speed from a large register file having a number of entries is also known.
For example, the device according to the patent document 5 includes a master register file (MRF) having a plurality of register windows, a current window register (CWR) holding a copy of data of the current register window indicated by a current window pointer (CWP), a current window replace buffer (CRB) pre-reading and holding data of a register window to be next held in the CWR, and an operation unit for performing an operation after reading data from the CWR or the CRB.
However, there is the problem that a mechanism to be debugged cannot be sufficiently debugged if a simulated fault is generated in a conventional method in a CPU having a plurality of register files. For example, assume that the register file 101 in FIG. 1 is configured by a large register file (hereinafter referred to as an MRF short for a master register file) having a number of entries, and a small register file (hereinafter referred to as an WRF short for a working register file) that copies the data of only a part of the entries in the MRF and holds the data. Also assume that the operation unit 102 reads data from the WRF, and the operation result is written back to both MRF and WRF.
In this case, with the configuration in FIG. 1, the same simulated fault data output from the simulated fault data generation circuit 104 is written to both MRF and WRF. Therefore, the patterns that can be simulated by the simulated fault data generation circuit 104 are only those in which the same faults simultaneously occur in both MRF and WRF configuring the register file 101.
That is, with the conventional configuration in FIG. 1, it is not possible to simulate a fault occurring only in the MRF independent of the WRF and to individually debug a mechanism to be debugged which is provided for the MRF. However, it is important to simulate a fault occurring only in the MRF and to perform debugging to confirm whether or not the fault is correctly detected and the data is correctly corrected. Therefore, the function to simulate the fault occurring only in the MRF is demanded.
One of the reason is that it is possible to recover the WRF from the MRF, but not possible to recover the MRF from the WRF. Even if a fault occurs in the WRF, the data in the WRF can be easily recovered by re-copying the data from the MRF as long as the MRF is in the normal state. However, if a fault occurs in the MRF, the data in the MRF cannot be recovered from the WRF because only apart of the data held by the MRF is stored in the WRF. Therefore, for example, it is necessary to take a measure to recover data in the MRF by reading data from cache memory or main memory etc. That is, since a fault occurring in the MRF has a larger influence than a fault occurring in the WRF, the function of simulating a fault occurring only in the MRF is important.
Another reason is that since the MRF is larger than the WRF, the frequency that soft errors occur in the MRF because of a neutron etc. is higher than the frequency that soft errors occur in the WRF. Thus, the practical frequencies of occurrences of faults are different. Accordingly, the function of simulating a practical pattern in which a fault occurs in the MRF but not in the WRF is demanded.    [Patent Document 1] Japanese Laid-open Patent Publication No. 58-043044    [Patent Document 2] Japanese Laid-open Patent Publication No. 59-200349    [Patent Document 3] Japanese Laid-open Patent Publication No. 61-267840    [Patent Document 4] Japanese Laid-open Patent Publication No. 4-109340    [Patent Document 5] Japanese Laid-open Patent Publication No. 2007-087108